Subject: BOOPSI Object Streams (BOS) URL
X-Homemail: mailto:efp90@nuke.dircon.co.uk
X-Url: http://www.users.dircon.co.uk/~nuke/
Resent-Message-Id: <"IM02Z3.0.x25.IKiin"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/1472
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
X-Lines: 17
Status: RO
Content-Type: text/plain
Content-Length: 452
Hi,
Following on from the `Method madness: the Truth' discussion and
my `spouting off' I've prepared a Web page for my BOOPSI Object
Streams stuff:
http://www.users.dircon.co.uk/~nuke/BOS.html
It's basically just a pretty good explaination at the moment,
but I'm still hoping to let people at this stuff mid-June; this
will be the mail-list and that is the page where you can hear about
it first...
Thanks to those who've shown interest!!
Ellis.
Subject: Re: BOOPSI Object Streams (BOS) URL
References:
X-Homemail: mailto:efp90@nuke.dircon.co.uk
X-Url: http://www.users.dircon.co.uk/~nuke/
Resent-Message-ID: <"ll7Uo1.0.AT6.t5Ojn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1484
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 70
Status: RO
Content-Type: text/plain
Content-Length: 2821
Hi Hans,
> My Garbage Collector have an ID allocater so that every object
> gets an unique ID. I can then save the object on a stream like
> this:
>
> ------------
> | ID | -> Objects unique ID, I can allways find it.
> ------------
> | Size | -> Size of all data below (It's not an IFF :)
> ------------
> | Class ID | -> Then we know what class to create.
> ------------
> | Object | -> Whatever data the object wants to have saved.
> | data |
> ------------
>
> This way an object can tell the streamobject to save or - if there
> allready is one on the stream with the same ID - overwrite it.
> Also a containerobject could use the unique ID's to keep track of
> the objects it contains if it where to be saved on the stream.
Probably not... if I've understood you correctly!
The `id' is basically the address of the object; on store,
when the Stream class receives the MUIM_Stream_StoreObj method
it first looks up the address of the object in a
stream-private table; if it is not found then it makes an
entry, generating a unique id on the fly (actually the index
into the table) and writes the class data; if it is found then
it just writes the id.
On ReadObj the Stream object will either get an `object is
coming' delimiter or an `object reference is coming'
delimiter from the stream, if this is an `object is coming`
then it looks up the class and calls NewObject(); the class's
ReadFrom method has to take care of making sure that it is
entered into the `load-table' for multiple-reference resolving
which it does by calling MUIM_Stream_RefReadObj as soon as it
gets an Object * from it's ultimate `BOS-unaware' baseclass
(i.e. for a fully BOS class at the level above `rootclass'
and for a `built-on' class at the first level which knows
about BOS).
The Object * is then in the `load-table' and subsequently
when the stream reads a `object reference is coming'
delimiter it can read the id from the stream and simply index
into the load-table to find the pointer it should return.
This works!! I have code *now* using this stuff, it's also
not a new idea: our streaming stuff here at CAS works exactly
this way; I should know since I've re-coded this mechanism
recently to make it thread-safe (BOS is thread safe already!).
Hope I've understood what you meant! :*)
Anyway, the garbage collection stuff might be useful, did
you say this was for BOOPSI or what?
Incidentally, since you mention prefs, one of my example
classes is actually a preferences management class; you can
add `Tagged' preferences entries into this dataspace which can
either be a pure numerical value, a simple string or an
Object, and save and restore the whole lot using BOS. I was
going to keep this for myself :*), but I may well release this
too if people can find a use for it!
Ellis.
Subject: Re: BOOPSI Object Streams (BOS) URL
References:
X-Homemail: mailto:efp90@nuke.dircon.co.uk
X-Url: http://www.users.dircon.co.uk/~nuke/
Resent-Message-ID: <"napKp1.0.8s4.7Fgjn"@susi>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de
X-Mailing-List: archive/latest/1494
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de
X-Lines: 45
Status: RO
Content-Type: text/plain
Content-Length: 1709
Hi Hans,
> I don't see how you can make the index a unique ID? What if you
> remove an object from the mittle of the stream wouldn't this
> happen:
>
> 1 2 3 4 5 6 7 8 // ID's as indexes. Now we remove object
> // with ID 4.
> 1 2 3 5 6 7 8 // and create a new object
> 1 2 3 5 6 7 8 8 // giving 2 objects with same ID.
>
> I'm getting this right? I would like to have some smart ways of
> allocating ID's.
There is no provision for `removing an object from the middle of
a stream'; basically the whole lot gets streamed, or none of it...
This is purely an archive/un-archive mechanism.
> > Anyway, the garbage collection stuff might be useful, did
> > you say this was for BOOPSI or what?
>
> It's not for BOOPSI, but it should not be hard to make it so.
> Please be more specific about what in the garbage collection
> stuff could be usefull. I think BOS has it all covered, though
> I'm not totally sure.
BOS is only a system for object storage, it doesn't encompass
garbage collection; that sort of mechanism is quite useful when
you are throwing around alot of objects without any kind
of true `ownership'... at some point the object is no longer
refered to by anyone, so it gets `collected'. Of course in the
common case this situation does not arise; you know what object
owns something and whos responsibilty it is to delete it; but it
might be an interesting project!
> Well to save the whole lot is not that hard. MUI is allready doing
> it for some parts. It's the restoring last saved for a single
> object and save a single object in a big prefs file that is the
> hard part. Pushing one big application structure to the disk and
> back again is not that hard.
Sure.
Ellis.